It looks like you're creating a custom error response from the entity when something unexpected happens, but I don't believe we're doing this in .NET. I'm also not sure if this is the right thing for us to do since it hides the fact that an error occurred from Functions telemetry. Regardless of what design we think is best, we should do the same thing in both languages. Can you open an issue to review the implementation and track consistent error handling for agent invocations?

I agree, the experiences should be consistent.
Created an issue to track this separately - #2434

I've never seen this direct access of generators and send in durable Python apps before, and I don't think it's intended that we make this a normal part of the programming model. Why is this needed, and can it be replaced with something more conventional?

I've added a comment at the top of this file, but this is basically only for the advance cases where the customers want true parallelism with invoking multi-agents with generators.

 """Fan out to two domain-specific agents and aggregate their responses.

    Note: The generator protocol lets us extract the Durable Task objects so we
    can pass them to task_all for true parallelism. If you only use `yield
    from` on each run call, the agents execute sequentially.
    For sequential execution, you can simply use:
        physicist_result = yield from physicist.run(messages=prompt, thread=physicist_thread)
        chemist_result = yield from chemist.run(messages=prompt, thread=chemist_thread)
    """

The conventional method is defined throughout the rest of the samples with using the yield from model. The only catch here is that that convention is more synchronous -

email_result_raw = yield from email_agent.run(
        messages=email_prompt,
        thread=email_thread,
        response_format=EmailResponse,
    )

I understand what the sample is doing, but I don't understand why we can't use normal generator syntax. This is not something durable customers need to do in Python today: https://learn.microsoft.com/en-us/azure/azure-functions/durable/durable-functions-overview?tabs=in-process%2Cnodejs-v3%2Cv1-model&pivots=python#fan-in-out

The difference is in the response type of the types. The context.task_all expects a list[TaskBase] but the agent.run responds with a Generator[.., .., AgentRunResponse] due to which it can't resolve properly. The main reason why this is happening is because we do some post-processing after we get the result back from the entity after we signal it using context.signal_entity() and return an object of AgentRunResponse. Earlier, we were just returning the same task that we got when executing teh signal_entity command without any post-processing.

result = yield self.context.call_entity(entity_id, "run_agent", run_request.to_dict())

logger.debug(
    "[DurableAIAgent] Entity call completed for correlation_id %s",
    correlation_id,
)

response = self._load_agent_response(result)

if response_format is not None:
    self._ensure_response_format(response_format, correlation_id, response)

return response